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— ProSalus Functional Safety Engineering 


Safety Instrumented System 


Design and Development 
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Achieving the target SIL 


¢ Selection of Components and Sub Systems 

¢ Design to achieve the target PFD average 

* Design for safe behaviour on detection of a fault 
¢ Ensure functional independence from BPCS 

¢ Comply with fault tolerance requirements 

* Design to reduce common cause failures 


¢ Provide secure interfaces between components 
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Selection of Components and Subsystems 


Two paths to Functional Safety Compliance: 


1. All components and subsystems in the SIF loop are 
designed and tested in accordance with IEC 61508-2/3 


OR 


2. Evidence based on IEC 61511 “Prior Use” to demonstrate 
suitability of the SIF for a maximum target SIL2 
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For a SIF to qualif —<— 


Prior Use (11.5.3 
7 ee Build to IEC 61508-2 & 3 HW & SW 


ee | avige tg By acta Certify to IEC 61508 


SIL 1 or 2 


SIL 3 requires |. 
assessment and a safety 
Manual (11.5.4. ee 


i TEC 61511 
Limitations (11.5.4) 


es 


PFD must satisfy SIL target 
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Requirements for Device to be IEC 61511 “Proven-in-use” 


Evidence that the instrument is suitable for SIF 


= Consider manufacturer’s QA systems 


= PES devices need formal validation — 
IEC 61508-3 Annex A Table A.7 as starting point 


= Performance record in a similar profile 
= Adequate documentation 


= Volume of experience, > 1 yr exposure per case. 
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The approved safety instrument list 


" Each instrument that is suitable for SIF 
= Update and monitor the list regularly 

= Add instruments only when the data is adequate 

= Remove instruments from the list when they let you down 


= Adequate details: Include the process application 
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Selection of Components and Subsystems 
¢ IEC 61508 General requirements _ 


= Component developed to relevant IEC 61508 Part 2 & 3 requirements 
= Safety Manual provided for specific component IEC 61508-2 Annex D 
= Functional Specification, Hardware / software configuration 
= Constraints and limitations on use identified during analysis (FMEDA) 


= Failure Modes for device and device diagnostics (Specifically those 
device failure modes not detected by diagnostics) 


Failure Rates and Hardware Fault Tolerance 


Type classification A or B, Systematic capability 


Proof test, operating and maintenance requirements. 


Calibration and set up features identified. 
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Selection of Components and Subsystems 


* Field Devices 
= ‘An initiator or final element used as part of a SIS shall not be used for 
control purposes where failure of the control system would cause a 
demand on the protection system except when an analysis has been 
carried out to confirm that the risk is acceptable’ 


= De-energize to trip is the preferred action. 


= Energize to trip shall apply a continuous end-of-line monitor such as 
pilot current to ensure continuity. 


= Smart sensors shall have write protection enabled. 
= Must be suitable for the installed environment 


oi.e. Corrosion, temperature, humidity etc. 
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Sharing of Sensors with BPCS 
When possible do not share sensors because it: 
= Violates the principles of independence 
= Potential for a high level of common mode failure 
=" Cannot not be considered a separate layer of protection 
=" Creates maintenance and change control issues 


Separation Rules: Field Sensors IEC 61511 Part 1 : 11.2.4 
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Selection of Components and Subsystems 


¢ Field sensors 


=" If asensor is used for both BPCS and SIS then common mode failure 
considerations must be assessed 


= Sensor diagnostics must be capable of placing the process in a safe 
state if a CMF occurs 


=" The Hardware Fault Tolerance requirements are met 


=" Separate sensors with identical or diverse redundancy will normally be 
required for SIL 3 & SIL 4 depending on the SFF. 


= |f SIS sensors are connected to a BPCS suitable isolator / splitters 
must be used and meet the target SIL requirements. 
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Separate Sensors for Control and Trip FTA Example 


Boiler Steam 
Drum 
Feed water 
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FTA Example for Boiler Low Level Trip 


Shared Sensor 


Boiler Damage Boiler Damage 


Separate Sensor 


0.0075 / yr. 
Low level and NO TRIP 


0.105 / yr. 
Low level and NO TRIP 


FW Fails and LT-1 Fails 
No Trip high-No Trip 
LIC causes low 
level 


Low level 
0.3 /yr. 


LT-2 Fails high 
Trip fails on 
demand 


0.005 / yr. 


O.1/ yr. PFD = 0.1/2 X 0.5 
= 0.025 

FW Fails LT-1 Fails 

|__ high, LIC-1 

FW Fails Trip oe ee from 0.2 /yr. causes low 

allure 
0.2/yr. eve 
PED = 0.1/2 X 0.5 
= 0.025 0.1/yr. 
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Shared Sensor for Control and Trip 


Boiler Steam 
Drum 


Feed water 


Failure of the BPCS supply 


must not cause a failure 
in the SIS consider 
Splitter unit that is 
functionally safe 
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Selection of Components and Subsystems 


* Control and shutdown valves 
« Asingle valve may be used for both BPCS and SIS 
provided that: 


oA failure of the valve cannot cause a demand on the SIF 


o Diagnostic coverage on the valve and SIF will ensure safe 
reaction to a dangerous failure and common mode failure 
requirements are met. 


o Hardware Fault Tolerance requirements are met 


=» SIL3 and SIL 4 will normally require separate identical 
or diverse valves 
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Arrangement for Tripping of Shared Control Valve SIL 1 


Solenoid valve 
direct acting, 
direct mounted. 
De-energise to 
vent actuator. 


Positioner 


A/S 
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Diverse Separation of Control and Shutdown Valves SIL 2 & 3 


ii 
I 


Ss 
I 
A/S ; 
I 
I 
I 
I 
! 


Check hazard demands due to valve 
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Selection of Components and Subsystems 
¢ SIS Logic solver 


=" Functional separation between BPCS and SIS 
# Will have internal diagnostics to detect dangerous faults 
=" Can be PES, Solid State or Relay 


= When there are a large number of outputs then it shall 
be necessary to determine if any foreseeable failures or 
combination of failures can lead to an hazardous event 
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Design Considerations 


Types of Failure 


¢ The Integrity of a SIF is dependent on how often it fails 
dangerously. 


¢ There are two main types of failure which need to be 
addressed: 


=" Systematic failures; 
=» Random hardware failures 
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Design Considerations to meet the target Safety Integrity Level 


Design needs to evaluate the potential for random hardware failures 
and for systematic errors in design or in software 


Random hardware failures. Systematic failures 
Adequate measures to avoid 
Each subsystem must satisfy SIL systematic errors during design. 
tables for HW fault tolerance * project procedures 
* safety lifecycle methods 
* verifications 


Each subsystem must satisfy 
SIL tables for PFD or PFH 
| Software engineering design must 
incorporate safety techniques and 
Overall system must satisfy SIL measures appropriate to required SIL 
tables for PFD or PFH 


SIL rating of the safety function defined by the lowest SIL of the above | 
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Systematic Failures 


¢ A failure related in a deterministic way to a certain cause, 
which can only be eliminated by a modification of the 
design or the manufacturing process, operational 
procedures, documentation or other relevant factors: 
" Safety requirements specification; 
= Design; 
= Manufacture; 
= Installation; 
= Operation; 
= Maintenance 
* Usually due to a human error, design fault-wrong 
component, incorrect specification error in software 
program, error in testing. 
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Systematic failures 


« Asingle systematic fault can cause failure in multiple 
channels of a redundant system. 


« Systematic failures, by their very nature, cannot be 
accurately predicted because the events leading to them 
cannot be easily predicted. 


= Functional safety standards protect against systematic 
faults providing rules, methods and guidelines to prevent 
design errors. 


» Asystem implemented using such methods should be 
relatively free of systematic errors. 
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Random Failures 


¢ A failure occurring at a random time, which results 
from one or more of the possible component 
degradation mechanisms. 
» Random failures rates can be predicted with reasonable 
accuracy depending on the quality of the data 
o E.g. Generic, Industrial or Site failure rate data 
¢ Safe failures 


¢ Dangerous failures 
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Random Failures 


¢ Failure Rate data: 
= Number of failures per unit / component as either: 
o Aconstant failure rate; 
o An average failure rate over a period / mission time 


* Dangerous failures are those that prevent success when 
there is a demand: 
o Fails to operate when required i.e. valve fails to close 
o Worse are dormant failures — undetected dangerous failures 
o Potential consequences due to failure to prevent hazard occurring 


¢ Safe failures are spurious or nuisance failures: 
o Spurious or nuisance shutdown no demand from process to trip 
o Downtime due to fault detection and restart 
o Loss of production / profits 


ProSalus Limited Slide 5 - 23 


<r ProSalus Functional Safety Engineering 


IEC 61508 / 61511 Modes of Operation 
¢ Three modes to consider: 
= Low 
= High 
=" Continuous 


¢ Most process plant SIFs are ‘low demand mode’ 
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Functional Safety Engineering 


Demand Modes 


* Low demand mode: 
« An infrequent demand rate on a protective system; 
= No greater than once per year 
= Use Probability of Failure of Demand average (PFDavg) 


* High demand: 


= The demand rate is greater than once per year 
= Use average frequency of dangerous failure (PFH) 


* Continuous demand 
= Dangerous failure will lead to a potential hazard without any further 


failure 


= Use average frequency of dangerous failure (PFH). 
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Demand modes 


Demand mode-61511 Continuous mode - 61511 


Low demand - 61508 


High demand - 61508 


Continuous - 61508 


Use PFD,,, 


Use probability of 
failure per hour 


Use probability of 
failure per hour 


Take credit for proof 
testing 


No credit for proof 
testing 


No credit for proof 
testing 


Take credit for 
automatic diagnostics 


Take credit for 
automatic diagnostics 


No credit for automatic 
diagnostics 
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Average Probability of Failure on Demand 
¢ Asstatistical probability or chance that a system will not perform 
its intended function when demanded. 
¢ Valid for ‘low demand mode’ operation only 


Average frequency of dangerous failure 

¢ The average frequency of a dangerous failure of system to 
perform the specified safety function over a given period (PFH). 

¢ Valid for ‘high demand and continuous mode’ operation only 

¢ When the system is the ultimate layer PFH is calculated from 
unreliability F(t) = 1-R(t) approximates to F(t)/T & 1/MTTF 

« When the system is not the ultimate layer PFH is calculated from 
unavailability U(t) and approximates to 1/MTBF 
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Understanding Types of Failures 


For a low Demand System SIFs can fail in two ways: 
+ Dangerous failure (hidden, covert or un-revealed) 
« Loss of protective function, but not aware until demand 
: Failure rate can be reduced by hardware fault tolerance (e.g. 1002 or 1003 
« Diagnostics can also be used. 


- Safe failure (revealed, evident — mostly economic) 
« Spurious or nuisance trip or alarm 
» No loss of protection 


» Spurious failures can be reduced by “revealed failure robustness” (e.g. 
2002 or 2003) 
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Which type of failures have impact on the SIF? 


Many failures do not influence the safety function at all, and so they are not 
considered anymore. Example: Display, Keypad, HART communication). 


In safety engineering we need to differentiate between safe and dangerous 
failures, 
and, if they are detectable or not (undetectable). 


Safe failures impact on the SIF‘s availability, but not on the safety 
function. 


Dangerous failures are split into detected and undetected. 


Dangerous detected failures are detectable by diagnostic and will raise a 
diagnostic alarm or trip system into a safe state. 
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Understanding Types of Failure 
(Detectable (Undetectable 


(Safe) sp sy 


Dangerous) ae Ga! 


Depending on the kind of evaluation safe and detectable 
failures can force a system to go into the safe state. 


Output transistor becomes defective, 

signal = 20 mA, central controller 

triggers (maintaining) gas alarm: 
ate! 


Signal cable to transmitter cut, 
Signal is 0 mA, central controller 
detects it: 


Dangerous RAM-failure, being 
Xx detected during automatic cyclic 
DD RAM-test, controller detects failure: By SAGA 
ate! 5 wi oe i 
The Dangérous Undetectable failure (Apu) is in the main focus of the SIL- 
consideration. 


iN Loss of measuring function 
DU without indication: Unsafe — 
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Design Considerations 


¢ Improving reliability and integrity 
« Hardware fault tolerance; 
= Multiple devices: 


o 1002, 1003 etc. 


¢ Avoidance of nuisance or spurious trips: 
« Voted multiple devices 


o 2002, 2003 etc. 
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Diagnostic Capability 


™ Ability of a sub system to automatically detect dangerous 
failures and take a action by: 
™ Bringing the process to a safe state 


™ Alerting the operator to take action — the diagnostic alarm should be 
included in the SIS in this case 


™ Thus when considering dangerous failures: 


™ \yq = those dangerous failures that are detected by 
diagnostics: 


™ Ay, = those dangerous failures that remain undetected by 
diagnostics and are only detected during Proof Testing 
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Diagnostic Coverage 


™ The Diagnostic Coverage (DC) of a component or sub system is 
defined as the ratio of the average rate of dangerous detected 
failures of the component or sub system to the total average 
dangerous failure rate of the the component or sub system 


™ DC normally determined by FMEDA 


™ For pre certified or pre approved equipment the DC is included on the 
certificate of conformance 


Diagnostic Coverage = > App 
App + ADU 
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Design Considerations - Sensor Diagnostics 


= Do not confuse with proof testing 


™ Integral to the device, designed in after OEM FMEDA has been 
completed to determine potential diagnostic mechanisms 


™" Must ensure diagnostic output is used and either trips the SIF or 
operator is trained to understand requirements of diagnostic alarms 
or NO credit for diagnostics should be taken in calculations 


Could compare trip transmitter value with related variables when 
practicable but not a secure method and puts more pressure on 
operator 


Diagnostic alarm test must be included in proof test to ensure 
operator awareness stays high 
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Valve Diagnostics 
Failure Mode % Contribution %Detection by % Of Dangerous 
to dangerous partial closure test Faults Detected 
failures 
Actuator spring breakage 20 70 14 
or jamming 
Solenoid fails to vent 5 50 2.5 
Positioner fails to trip 3 100 5 
Hoses kinked or blocked 10 100 10 
Valve stem or rotary shaft 40 70 28 
stuck 
Actuator linkage fault 3 70 3:5 
Seating failures of valve 10 0 0 
causing high leakage. Due 
to erosion or corrosion 
Foreign bodies or sludge 5 0 0 
preventing full closure 
Total 100% 63% 
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Methods for Valve Diagnostics 


* On-line functional testing 

» Limit switch discrepancy / mismatch alarm 

« Position feedback 

« Partial closure testing — manual or automatic 


» Smart Positioner — certified safety Positioner 
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Architectural Constraints 
Subsystem Safety Integrity 
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SAFETY CONSULTANTS 


Architectural Constraints and Hardware Fault Tolerance 


Hardware Fault tolerance: 


Hardware fault tolerance is the ability of a system to continue to be able 
to undertake the required safety function in the presence of one or more 
dangerous faults in hardware. Hence a fault tolerance level of 1 means 
that a single dangerous fault in the equipment will not prevent the system 


from performing its safety functions. 


From the above it follows that a fault tolerance level of zero implies that 
the system cannot protect the process if a single dangerous fault occurs 


in the equipment. 
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SIL of the overall SIS is defined by the lowest SIL of the subsystems 


Sensor eo Logic ——— Actuator 
\ / 
N\ ! 7 
SIL 1 N SIL2 7 SIL 1 
Subsystem \ Subsystem 7 Subsystem 
\ I 7 
\ I vA 
% v i 
e Overall SIS e 
SIL 1 
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Safe Failure Fraction 


™ The Safe Failure Fraction (SFF) of a sub system is defined as the 
ratio of the average rate of safe plus dangerous detected failures of 
the sub system to the total average failure rate of the sub system 


™ SFF normally determined by FMEDA 


™ For pre certified or pre approved equipment the SFF is included on 
the certificate of conformance 


Safe Failure Fraction = > As+ YApp 


> As+ y App + yADU 
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Architectural Constraints 


™ IEC 61508 places an upper limit on the SIL that can be 
claimed for any SIF on the basis of the HFT of the 
subsystems that it uses. 


= Limit is a function of 


™ Device Type Aor B 


™" The degree of confidence in the behaviour under fault 
conditions 


™ Safe Failure Fraction 


= Hardware fault tolerance 
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IEC 61508 Classification of Equipment 


IEC 61508 defines two types of equipment for use in SIS: 


=" Type A: Simple Devices: Non PES — where failure modes 
and fault behaviour are well defined and there is 
dependable failure data 


™" Type B: Complex Devices: Including PES - where failure 
modes and fault behaviour are not well defined and there is 
insufficient dependable failure data 

™" Fault tolerance rating of B is less than A for equivalent SFF 
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IEC 61508 Table 2 
Minimum hardware fault tolerance of type A sub systems 


Minimum HW Fault Tolerance 


SFF<60% | SFF.60% to.90% =| 60% | SFF.60% to.90% =| 90% SFF>90% SFF>99% 


For devices with well defined failure modes, 
predicable behaviour and field experience. 
Normally excludes PES 
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IEC 61508 Table 3 
Minimum hardware fault tolerance of type B sub systems 


Minimum HW Fault Tolerance 


SFF 60% to 90% SFF>90% SFF>99% 


For devices with some none defined failure modes 
OR unpredictable behaviour 
OR insufficient field experience 
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IEC 61511-1 Table 6 
Minimum hardware fault tolerance of sensors, final elements & non PES logic 


Minimum HW Fault Tolerance 


Special requirements: See IEC 61508 


The following summarized conditions apply for SIL 1,2 and 3 : 
Increase FT by 1 if instrument does not have fail safe characteristics 
Decrease FT by | if instrument if the device complies with the following. 
* The hardware is selected on the basis of prior use (IEC 61511 11.5.3) 
* The device allows adjustment of process related parameters only, for example, measuring range, upscale or 
downscale failure detection. 
* The adjustment of the process related parameters of the device is protected, for example jumper, password. 
* The function has a SIL requirement of less than 4. 


Alternatively tables 2 and 3 of IEC 61508 may be applied if the SFF can be calculated 
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Architecture rules for PES logic solvers 


IEC 61511-1 Table 5 
Minimum hardware fault tolerance of PE logic solvers 


Minimum HW Fault Tolerance 


SFF 60% to 90% SFF>90% 


ee | Special requirements: See IEC 61508 


Alternatively tables 2 and 3 of IEC 61508 may be applied with 
an assessment 
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Example Minimum Architectures for Fault Tolerance of 
Type A and B Sub-Systems for 60% to 90% SFF 


Simple Devices (Non PES) Complex Devices 
Type A Type B 


Safety Integrity. Min. Fault Minimum Min. Fault Minimum 
tolerance. Architecture tolerance. Architecture 


SIL 1 0 lool 0 lool 


SIL2 0 lool 1 1oo2 or 2003 


SIL3 1 loo2 or 2003 2 1o03 


SIL4 1003 Special requirements apply, 
see IEC 61508 
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Architectures for Safety Systems - 1001 Single channel 


1001D has a higher safe failure fraction than 1001 but is still not able to 
protect the plant if a fault remains hidden 


lool Fault Tolerance: ? 
lool D Fault Tolerance: ? 


¢ 
i 
Diagnostics P7777 7 ¢ 
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Architectures for Safety Systems - 1002 v 2002 


loo2 


Fault Tolerance: ? 


2002 


Fault Tolerance: ? 
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Performance attributes of sub-system architectures 
Sub system Fault Selection Guide 
structure tolerance 
lool 0 Use if both PFD and nuisance trip targets are met. 
loo2 1 2 Sensors installed, 1 required to trip. PFD value 
improved, nuisance trip rate doubled. Often suitable for 
SIL 2 
2003 1 3 Sensors installed, 2 required to trip. PFD improved over 
lool, nuisance trip rate dramatically reduced. 
loolD 0 Internal and external diagnostics used to improve safe 
failure fraction. Alternative to 1002 for SIL2 
1loo2D 1 As for 1oo1D but able to tolerate 1 fault and revert to 


1o01D during repair. 

Meets SIL 3 if safe failure fraction exceeds 90%. Does 
not satisfy diversity for SIL3 if sensors are identical. 
Reduces spurious trip rate, good alternative to 2003 
1003 2 3 Sensors installed, | required to trip. PFD improved over 
1oo02 but not by much unless diverse instruments are 
used. Nuisance trip rate may be a problem. Likely to be 
used for SIL 2 or 3. 

2004 2 Configured as two voting pairs of loo2D. Very high 
performance when used in logic solvers. Achieves SIL 3 
performance with | pair off line for repair. 
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Safe Failure Fraction - Issues 
=" Optimistic claims for dangerous failures that can be detected by 
diagnostics 


=" FMEDA is considered best practice for assessing dangerous 
failures that can be detected by diagnostics 


= If the detected failure claim is to optimistic then the safety integrity 
will be compromised due to the reduction in Hardware fault 
tolerance 
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Common Cause & Common Mode Failures 


* ACCF occurs when a single fault results in the 
corresponding failure of multiple components. 


* Common mode failures are a subset of common 
cause failures’ 


=» “A common-mode failure (CMF) is the result of an event (s) 
which because of dependencies, causes a coincidence of 
failure states of components in two or more separate channels 
of a redundancy system, leading to the defined system failing to 
perform its intended function”. 
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Common Cause Failures in Sensors 
=" Wrong specification 
™ Hardware design errors 
™ Software design errors 
" Environmental stress 
™ Shared process connections 
=" Wrong maintenance procedures 
" Incorrect calibration 
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Design Issues: 
Redundancy in Sensors 


Be careful to analyze for 
common cause faults 
eg. Try to avoid this 
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Common Cause Failures (IEC 61508) 


¢ IEC 61508 Part 6 Annex D —Method for quantifying CCF 
* 2010 version updated and based on PDS methodology 


¢ Based on the following factors from IEC 61508-6 Table D.1 to D5: 
* Separation/segregation; 
* Diversity/redundancy; 
*« Complexity/design/application/experience; 
« Assessment/analysis & feedback of data; 
« Procedures/human interface; 
* Competence/training/safety culture; 
¢« Environmental Control; 


« Environmental Testing. 
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Table D.1 — Scoring programmable electronics or sensors/final elements 


Item Logic Sensors and 
subsystem | final elements 


= ProSalus she | tt 


= SAFETY CONSULTANTS Separation/segregation 
Are all signal cables for the channels routed separately at all positions? 1,5 1,5 
‘Are the logic subsystem channels on separate printed-circult boards? 3,0 | 1,0 
Are the logic subsystem channels in separate cabinets? 25 | 05 


If the sensors/final elements have dedicated control electronics, is the electronics for each 
channel on separate printed-circuit boards? 

If the sensors/final elements have dedicated control electronics, is the electronics for each 
channel indoors and separate cabinets? 

Diversity/redundanc; 

Do the channels employ different electrical technologies 7,0 
for example, one electronic or programmable electronic and the other relay? 
Do the channels employ different electrical technologies 5,0 
for example, one electronic, the other programmable electronic? 

Do the devices employ different physical principles for the sensing elements 

for example, pressure and temperature, vane anemometer and Doppler transducer, etc? 
Do the devices employ different electrical principles/designs 

for example, digital and analogue, different manufacturer (not re-badged) or different 
technology? 

Do the channels employ enhanced redundancy with MooN architecture where N> M+ 2? 2,0 05 
Do the channels employ enhanced redundancy with MooN architecture where N=M+2? | 1,0 | 05 
Is low diversity used, for example hardware diagnostic tests using the same technology? 2,0 1,0 
Is medium diversity used, for example hardware diagnostic tests using different technology?| 3,0 | 1,5 
Were the channels designed by different designers with no communication between them 1,0 1,0 
during the design activities? 
‘Are separate test methods and people used for each channel during commissioning? 10 | 05 
Is maintenance on each channel carried out by different people at different times? 2,5 
Complexity/design/application/maturity/experience 
Does cross-connection between channels preclude the exchange of any information other 05 ] 05 
than that used for diagnostic testing or voting purposes? 
Is the design based on techniques used in equipment that has been used successfully in 05 | 1,0 
the field for > 5 years? 
Is there more than 5 years experience with the same hardware used in similar 1,0 1,5 
environments? 
Is the system simple, for example no more than 10 inputs or outputs per channel? 1,0 
Are inputs and outputs protected from potential levels of over-voltage and over-current? 15 05 
Are all devices/components conservatively rated (for example, by a factor of 2 or more)? 2.0 
Assessment/analysis and feedback of data 
Have the results of the failure modes and effect analysis or fault-tree analysis been 3,0 
examined to establish sources of common cause failure and have predetermined sources of 
common cause failure been eliminated by design? 

Were common cause failures considered in design reviews with the results fed back into the 3,0 
design? (Documentary evidence of the design review activity is required.) 


‘Are all field failures fully analysed with feedback into the design (Documentary evidence of | 0.5 | 3.5 
the procedure is required. 
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Logic Sensors and 
subsystem | final elements 
[x [sy] sXs] Ys | 


Procedures/human interface 
=_ ProSa | U iS Is there a written system of work to ensure that all component failures (or degradations) are 
ed detected, the root causes established and other similar items inspected for similar potential 
SAFETY CONSULTANTS causes of failure? 
‘Are procedures in place to ensure that: maintenance (including adjustment or calibration) of 
any part of the independent channels is staggered, and, in addition to the manual checks 
carried out following maintenance, the diagnostic tests are allowed to run satisfactorily 
between the completion of maintenance on one channel and the start of maintenance on 
another? 
Do the documented maintenance procedures specify that all parts of redundant systems 
(for example, cables, etc.) intended to be independent of each other, are not to be 
relocated? 
Is all maintenance of printed-circuit boards, etc. carried out off-site at a qualified repair 
centre and have all the repaired items gone through a full pre-installation testing? 
Does the system have low diagnostic coverage (60 % to 90 %) and report failures to the 
level of a field-replaceable module? 
Does the system have medium diagnostics coverage (90 % to 99 %) and report failures to 
the level of a field-replaceable module? 
Does the system have high diagnostics coverage (>99 %) and report failures to the level of 
a field-replaceable module? 
Does the system diagnostic tests report failures to the level of a field-replaceable module? 
Competenceltraining/safety culture 
Have designers been trained (with training documentation) to understand the causes and 
consequences of common cause failures? 
Have maintainers been trained (with training documentation) to understand the causes and 
consequences of common cause failures? 
Environmental control 
[= personnel aczess ined (or exemple orked cabinets, naezessible posiven)? ———_{_os | a5 | os | 25 | 
i the system likely to operate always within the range of temperature, humidity, corrosion, 
dust, vibration, etc., over which it has been tested, without the use of external 
environmental control? 
Are all signal and power cables separate at all positions? 
Environmental testing 
Has the system been tested for immunity to all relevant environmental influences (for 
example EMC, temperature, vibration, shock, humidity) to an appropriate level as specified 
in recognized standards? 


NOTE 1 Anumber of the items relate to the operation of the system, which may be difficult to predict at design time. In these 
cases, the designers should be make reasonable assumptions and subsequently ensure that the eventual user of the system is. 
made aware of, for example, the procedures to be put in place in order to achieve the designed level of safety integrity. This 
could be by including the necessary information in the accompanying documentation. 


NOTE 2 The values in the X and Y columns are based on engineering judgement and take into account the indirect as well as 
direct effects of the items in column 1, For example, the use of field-replaceable modules leads to 


- repairs being carried out by the manufacturer under controlled conditions instead of (possibly incorrect) repairs being made 
under less appropriate conditions in the field, This leads to a contribution in the Y column because the potential for systematic 
(and, hence, common cause) failures is reduced; 


- a reduction in the need for on-site manual interaction and the ability quickly to replace faulty modules, possibly on-line, so 
increasing the efficacy of the diagnostics for identifying failures before they become common-cause failures. This leads to a 
strong entry in the X column. 
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Table D.2 — Value of Z: programmable electronics 
Diagnostic Diagnostic test interval 
Soverage. Less than 1 min Between 1 min and 5 min Greater than 5 min 


299% 2,0 
290% 1,5 
1,0 


Table D.3 - Value of Z: sensors or final elements 


Diagnostic Diagnostic test interval 


coverage Less than2h Between 2h and | Between2days | Greater than one 
two days and one week week 


299% 1,5. 1,0 
9 


Table D.4 — Calculation of Aint or pin 


Score (S or Sp) Corresponding value of fi or fo for the: 


Logic subsystem Sensors or final 
elements 


120 or above 


70 to 120 
45 to 70 


NOTE 1 The maximum levels of fp shown in this table are lower than would 
normally be used, reflecting the use of the techniques specified elsewhere in 
this standard for the reduction in the probability of systematic failures as a 
whole, and of common cause failures as a result of this. 


NOTE 2 Values of fp lower than 0,5 % for the logic subsystem and 1 % for Slide 5 - 58 
the sensors would be difficult to justify. 
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Table D.5 — Example values for programmable electronics 


Category Diverse system Diverse system Redundancy Redundancy with 
with good with poor system with good | poor diagnostic 
diagnostic testing | diagnostic testing | diagnostic testing testing 
Separation/segregation 
14,50 14,50 
a 


Diversity/redundancy 4 A 
Complexity/design/.... 2,75 2,75 2,75 27 


2,25 2,25 2,25 2,25 
Assessment/analysis/.... 0,25 0,25 0,25 0,25 

4,75 4,75 4,75 4,75 
Procedures/human interface 3,50 3,50 3,50 3,50 

3,00 3,00 3,00 3,00 
Competenceltraining/.... 1,25 1,25 1,25 1,25 

3,75 3,75 3,75 3,75 
Environmental control 2,75 276 2,75 emis] 

2,25 2,25 2,25 2,25 
Environmental test 5,00 5,00 5,00 5,00 

5,00 5,00 5,00 5,00 
Diagnostic coverage 2,00 0,00 2,00 0,00 
Total 33,5 33,5 21 21 
Total ¥ 
Score S 59 
rm 
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Common Cause Failures (IEC 61508) 


¢ Using the IEC 61508 Part 6 Annex D £-factor model 
* Common Cause failure rate is ApB 
¢ Where diagnostics are available overall CCF rate is 


NpuB + AppBp 


¢ Using Table D1, D2, D3 and D4 
° B- S=X+Y=6,,; fora 1002 System 
Bp- Sp = X (Z+1) + Y = Bp in for a 1002 System 
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Common Cause Failures 


¢ Apply Table D5 for systems with levels of redundancy 
greater than 1002 , table based on PDS Method 


* IEC 61508-3, Annex D, Table D.4 for 1002 
* 0.01 —0.1 for field equipment; 


* 0.005 —0.05 for programmable electronic systems 
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Common Cause Failures - Systems Diagram 1002 


=» Consider a simple 1002 redundant subsystem 


ha 


A, 


cc 


ha 


Common cause 
failures 


Aq = total dangerous failure rate 

Aec = total common cause failure rate 

Nec = Brg 

Where B = the common cause failure factor 
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Common Cause Failure Calculation - Example 


Neg =A 
Nec = BAg 

Where: 

Ag =0.05 failures / year 

B =0.1 

Therefore 

Noc= 9.1 * 0.05 = 0.005 failures / year 


common cause 
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Common Cause Failures - Systems Diagram 1002 


Na 
Nec 
Na Common cause 
failures 


PFD.,, = (Ay? xT? + XT 
3 2 


Common Cause failure should be shown as an additional 1001 block in 
the RBD or as an input to an OR gate in an FTA and then summed with 
the 1002 block to calculate overall sub system PFDavg 
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Design Considerations - Field Devices Summary 


° Safety Related Instruments must well proven 
* Smart instrumentation treated as PES — Type B 
* Separation, Redundancy, Diversity design issues 


° Increased Diagnostic Coverage for improved SFF to reduce HFT 
requirements 


*® For SIL 1 and SIL 2 - justifification of suitability on “prior use”. 
¢ Requires evidence of previous usage in safety. 
* SIL 3 requires formal assessment (IEC 61511 11.5.4.4) 
¢ “Prior use” does not help if the instrument is new to your 
company unless the vendor can assist with Client data 
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Safety Component Selection 


=" Use Safety Certified / approved components to IEC 61508 wherever 
possible as this aids in the verification in terms of failure data, component 
type, safe failure fraction, available diagnostics 


=" Make sure Safety Manual is supplied with device / component. 

=" Ensure application and usage complies with vendor’s safety manual. 

= If you have records of the same instrument being used for an extensive 
period in safety applications you can document your own “Prior use” 


justification up to SIL 2 only. 


= Insist on verifiable data from Vendor / system supplier for the device / 
component either based on FMEDA, returns data or acelerated testing. 
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IEC 61511 Application Software 
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Software Safety Topics 


" Software for Safety 

" Software Verification & Systematic Errors 

= Software Management & Quality Assurance 
" Software Safety life cycle 

" Software Safety Requirements 


" Certification and compliance 
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Software for Safety 


= SIS software must have a proven QA/C (Testing) and FSM record 
= Software comes in two parts: Embedded and Application 
= Both parts require software QA/C & FS management procedures 


= Embedded software including development tools QA/C & FS 
management procedures and software construct should to be 3'4 
party certified to IEC 61508-3 with a report of limitations of use 


= Application tools should be certified for use with the OEM software 
package 


=" Development of Application software to follow IEC 61511-1 figures 
12 Software development lifecycle table 7 and comply with IEC 
61131 software language requirements. 
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Software Verification & Systematic Errors 


« IEC 61508-3 safety approved embedded / operating system and 
check versions are certified for use with hardware and application 
package 


« IEC 61508-3 precertified software modules (Function Blocks) 


* OEM approved application package matched to system hardware and 
software versions. 


« IEC 61511 Clause 12 for QA and FSM procedures for application 
software when using IEC 61508 compliant systems 


« IEC 61511 Software Validation by Testing against Requirement 
Specification and cause and effects 


¢ Software verification complicated — 61508 requires formal analysis & 
traceability (61508-7 Annex D) 
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Software Management and Quality Assurance 

» Management of Software Quality & Testing replaces reliability 
analysis 

" Software Quality Assurance practices are well established. 


» IEC 61508-6 Annex E Safety Manual requirements for Software 
Elements 


" Software Safety Life Cycle in IEC 61508-3 Annex G for detailed 
guidance on software lifecycles and IEC 61511 clause 12 


« IEC 61508-6 Annex E for example guidance on the application 
of the IEC 61508-3 software safety integrity tables 
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Software Safety Lifecycle: V model 


SIS SRS Validation Validation Validated 
Testing 14.3 sis 


ee 


Application Software SRS - Application software 
122 Integration test 


12.5 


a 
| 1 
L 
Application Software 
Architecture design 12.4.3 & 4 


Application Software Application Software 
development12.4.5 #777777 TTT Testing - 12.4.7 


Application Module Application Module 
Development -12.45 \@-—----------— Testing - 12.4.6 


Output Coding — 12.4.2.1 Code development and test — 
oe ; > FVL only (see IEC 61508-3) 
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Application Software Life Cycle Requirements 


« Application Software Safety Requirements Specification 

= Features and facilities required of the application language 

= Features to facilitate safe modification of the application 

= Architecture of the application software 

= Requirements for support tools, user manual and application languages 
= Software development methods 

= Software module testing 

= Software integration testing 

= Integration testing with the SIS subsystem 


Continues through to Validation, Operation, Proof testing and Inspection. 
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Specification of Application Software 


Software safety requirements, in terms of both the safety functions and the safety 
integrity, should be stated in the safety requirements specification. 


The specification should include all the modes of operation, the capacity and response 
time performance requirements, maintenance and operator requirements, self- 
monitoring of the software and hardware as appropriate, enabling the safety function to 
be testable whilst the plant is operational, and details of all internal/external interfaces. 


The specification should be written in a clear and precise manner and should be free 
from ambiguity and clear to those for whom it is intended. 


For SIL 2 systems, the specification should use semi-formal methods to describe the 
critical parts of the requirement (e.g. Safety related control logic). The semi-formal 
methods chosen should be appropriate to the application and typically include 
logic/function block diagrams, cause and effect charts, sequence diagrams, state 
transition diagrams, time Petri nets, truth tables and data flow diagrams. 
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Design and Development 


The design methods should aid modularity and embrace features which reduce 
complexity and provide clear expression of functionality, information flow, data 
structures, sequencing and timing related constraints and information and design 
assumptions. 


The system software (i.e. non-application software) should include software for 
diagnosing faults in the system hardware, error detection for communication links, and 
on-line testing of standard application software modules. 


In the event of detecting an error or fault the system should, if appropriate, be allowed to 
continue but with the fault redundant element or complete part of the system isolated. 


Detailed Design 


The detailed design of the software modules and coding implementation should result in 
small manageable software modules. Semi-formal methods should be applied, together 
with design and coding standards including structured programming, suitable for the 
application. 


The system should, as far as possible; use trusted and verified software modules, which 
have been used in similar applications. 


The software should not use dynamic objects, which depend on the state of the system 
at the moment of allocation, where they do not allow for checking by offline tools. 
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Programming Language and Support Tools 


The programming language should be capable of being fully, unambiguously defined 
and compliant with BS EN 61131-3. The language should be used with a specific coding 
standard and a restricted sub-set to minimise unsafe/unstructured use of the language. 


The support tools need either to be well proven in use (and errors resolved) and/or 
certified as suitable for safetv svstem application. 


Software Module Testing and Integration 


The individual software modules should be code reviewed and tested to ensure that they 
perform the intended function and by a selection of limited test data to confirm that the 
system does not perform unintended functions. 


As the module testing is completed then module integration testing should be performed 
with pre-defined test cases and test data. This testing should include functional, ‘black 
box’ and performance testing. 


The results of the testing should be documented in a chronological log and any 
necessary corrective action specified. Version numbers of modules and of test 
instructions should be clearly indicated. Discrepancies from the anticipated results 
should be clearly visible. Any modifications or changes to the software, which are 
implemented after any phase of the testing, should be analysed to determine the full 
extent of re-test that is required. 
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Overall Integration Testing 


The overall testing of the integrated system includes both hardware and software, 
detailed requirement are in BS EN 61508-3 Annex A Table A.6 the same requirements 
are repeated in BS EN 61508-2. 


The overall integration testing should be performed with pre-defined test cases and test 
data. This testing should include functional, ‘black box’ and performance testing. 


The results of the testing should be documented in a chronological log and any 
necessary corrective action specified. Serial, Version numbers and test instructions 
used be clearly indicated. Discrepancies from the anticipated results should be clearly 
visible. Any modifications or changes to the system, which are implemented after any 
phase of the testing, should be analysed to determine the full extent of re-test that is 
required. 


Validation 


Whereas Verification implies confirming for each stage of the design that all the 
requirements have been met prior to the start of testing of the next stage, validation is 
the final confirmation that the total system meets all the required objectives and that all 
the design procedures have been followed . 
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IEC 61508 Part 3 Overview 
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IEC 61508 Safety Certified PES Logic Solvers 


¢ TUV Publish a list of type certified systems on website 

¢ Ensure hardware and software versions are as per certificate 

* Check Test report for any limitations on use 

* Software representation complies with IEC 61131 requirements 


° Within the use of LVL software there is the possibility to create user 
defined function blocks, however they must be constructed and 
tested as FVL software modules to avoid human or specification 
errors 


* Certification can be directed at specific applications e.g. furnace 
control, HIPPS or for other typical process applications 
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IEC 61508 Software Verification 


" Software verification complicated — 61508 requires formal analysis 
& traceability (61508-7 Annex D) 


« Difficult and costly to test all foreseeable combinations of logic not 
normally considered in process applications reliance on SRS and 
C&E testing 


= The failure modes are unpredicatable in presence of hardware 
faults. 


= Re-use of old software in new applications (also known as 
SOUP. ..software of uncertain pedigree - Refer HSE guidance RR 
336/2001 & 337/2001 
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Table A.1 — Software safety requirements specification (see 7.2) 


TECHNIQUE/MEASURE * 


REF 


Functional Safety Engineering 


Computer-aided specification tools 


B.2.4 


Semi-formal methods 


Table B.7 


Formal methods 


Note 1 — The software safety requirements specification will always require a description of t 


any necessary mathematical notation that reflects the application. 


Note 2 — The table reflects additional requirements for specifying the software safety requirements clearly and precisely. 


e problem in natural language and 


* Appropriate techniques/measures shall be selected according to the safety integrity level. Alternate or equivalent techniques/ 
measures are indicated by a letter following the number. Only one of the alternate or equivalent techniques/measure has to be 


satisfied. 
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Table A.3 — Software design and development: (see7.4.4) 


TECHNIQUE/MEASURE * 


Functional Safety Engineering 


1 Suitable programming language 


2 Strongly typed programming language 


C41 


HR 


HR 


3 Language subset 


C42 


HR 


HR 


4a Certified tools and Certificated translators 


C43 


HR 


HR 


4b Tools and translators: increased confidence from use 


C44 


HR 


HR 


HR 


HR 


* Appropriate techniques/measures shall be selected according to the safety integrity level. Alternate or equivalent techniques/ 
measures are indicated by a letter following the number. Only one of the alternate or equivalent techniques/measure has to be 
satisfied. 
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Table A.4 — Software design and development: detailed design (see 7.4.5 and 7.4.6 


TECHNIQUE/MEASURE * 


la Structured methods 


1b Semi-formal methods Table B.7 


lc Formal design and refinement methods B2.2.2,C.2.4 


Computer-aided design tools 


Defensive programming C25 


Modular approach Table B.9 


5 Design and coding standards C.2.6, Table B.1 


Structured programming 


Use of trusted/verified software elements (if available) 


* Appropriate techniques/measures shall be selected according to the safety integrity level. Alternate or equivalent techniques/measures are indicated by a 
letter following the number. Only one of the alternate or equivalent techniques/measure has to be satisfied. 


ProSalus Limited Slide 5 - 83 


<< ProSalus Functional Safety Engineering 


Scope of compliance required for logic solver software 
products 


¢ SIS Logic Solver and I/O certified for use at the relevant SIL 

¢ All ofthe programming languages supported by the logic solver with 
any special safety functions and function blocks to be certified for 
compliance at the relevant SIL. 


¢ All restrictions and operating procedures required by the certifying 
organization to be stated in the user documentation. 


* Methodology for on-line testing using overrides to be approved by the 
certifying organization. 
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Software Proven in Use - IEC61508-7 B.5.4 Field experience 


For field experience to apply (very difficult in reality — different firmware 
versions and missing FSM of the software) 

— unchanged specification; 

— 10 systems in different applications; 

— 100000 operating hours and at least one year of service history. 


This documentation must contain at least 

— the exact designation of the system and its components, including 
version control for hardware; 

— the users and time of application; 

— the operating hours; 

— the procedures for the selection of the systems and applications 
procured to the proof; 

— the procedures for fault detection and fault registration as well as fault 
removal. 
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Summary 


" Software safety integrity is achieved through IEC 61511-12 software life 
cycle and company software quality assurance procedures 


» IEC 61508-3 is targeted at new PES devices but can be applied as 
necessary for end user support, but requires detailed knowledge 


" Certified software packages provide a secure platform for the end user 
to execute an application. 


= Vendor’s training and safety manual requirements must be applied 


=" IEC 61511-2 Clause 12 provides additional support but is informative 
only 
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